On the Use of VDM + + for Specifying

Language extensions have been suggested in the past to make VDM++ better suited for specification of real-time applications and tool support was developed to analyze these extended VDM++ models. Practical experiences with the language extensions and the supporting tools are discussed in this paper. Improvements to the language extensions and tool support are suggested. 1 Is there really a need for language extensions? One of the important qualities of formal techniques is that abstraction is used to focus on the core properties of the system design. In particular the topics concurrency and real-time have a long standing tradition in academic research providing notations, tools and techniques to do just that. But it seems that the practical application of these solutions has not propagated sufficiently towards industry, particularly not to the mainstream of computing. The formal notations proposed by academia are in general very powerful and expressive but they are often not compatible with (or rather disruptive to) traditional system design, and in the past they did not scale up to the size of a typical industrial design problem which posed a high hurdle for their practical application. One could, most likely successfully, argue that the traditional industrial design approach in many cases is fundamentally flawed and that the current way of working should therefore not hinder introduction of obviously superior techniques, even despite the scalability issue. It is the experience of the author however, that making small incremental improvement steps from the existing situation, bringing more and more formality into the design process, has a much better chance of acceptance in industry than the revolutionary approach. The pragmatic introduction of formal techniques in combination with existing informal techniques and development processes is often referred to as “lightweight” or “invisible” formal methods [1,2]. The Danish company IFAD has been notably successful in the 1990’s, marketing and selling their product ? This work has been carried out as part of the Boderc project under the responsibility of the Embedded Systems Institute. This project was partially supported by the Netherlands Ministry of Economic Affairs under the Senter TS program. ?? and Radboud University Nijmegen, Institute for Computer and Information Sciences, P.O. Box 9010, 6500 GL Nijmegen, NL. http://www.cs.ru.nl/ita/ VDMTools, in support of the VDM notation, leaving a track record of several very successful and large-scale industrial applications of VDM. In 2005, the Japanese company CSK bought the intellectual property rights to these tools and furthermore a new book appeared describing both the VDM++ notation and the tool, see [3]. These industrial VDM++ projects, which are partly discussed in the book, have shown that formal languages, tools and techniques are actually easy to adopt in practice, especially if they can be used in combination with informal techniques. They merely require additional training of the technical experts, assuming basic knowledge of mathematics and logic. These domain experts are normally rather open to new ideas, in particular if it directly supports their task at hand. The challenge in industry however is to become productive fast and bridging the gap between a concrete design problem and abstract specification always seems to be the bottleneck, often due to lack of experience. The Model Driven Architecture, as proposed by the Object Management Group (see http://www.omg.org/mda), addresses this problem by creating socalled platform specific models (PSM), platform independent models (PIM) and a set of mapping rules between those models. PSMs are used to capture and communicate domain specific information, PIMs are abstractions that focus on some essential system properties. The mapping rules should facilitate automatic transformations between these models. Although this approach seems very appealing, it has not yet been proven to work in practice, in particular if the “semantic distance” between the PSM and PIM is big. Another approach is to integrate different languages, such as the Circus language [4] which combines the formal notations Z, CSP and refinement calculus into a single paradigm. Alternatively, one could consider extending an existing notation such that it is easier to express domain specific problems directly in that language. Sometimes it suffices to introduce some “syntactic sugar” or modeling patterns to ease specification of some problem, but leaving the original language semantics intact. If this doesn’t suffice, both the syntax and the semantics of the language need to be extended. However, the advantage over the MDA approach is still that large parts of the syntax and the semantics of the original language can often be reused. Already in 2000, as part of the ESPRIT project VICE (VDM++ In a Constrained Environment), language extensions where proposed to facilitate specification of real-time systems in VDM++. These language extensions were accompanied by a special version of VDMTools which enabled the analysis of these enhanced models. Both the language extensions and the tool have been around for a while now but only very little experiences are reported on the use of either. Purpose of this paper. A small case study was performed using the extended VDM++ notation and the supporting tools in the context of the BODERC project (Beyond the Ordinary: Design of Embedded Real-time Control) at the Embedded System Institute (see http://www.esi.nl/boderc). Without claiming to be complete, some valuable lessons learnt can already be drawn from this modeling exercise. These observations are intended to revitalize the debate on extending the VDM++ language for specifying real-time systems. This paper is organized as follows. First, we explore how real-time systems can be modeled using the proposed extensions to VDM++. Some observations are made based on a case study and finally we suggest some improvements to the language and the supporting tools. 2 What is required for specifying real-time systems? The unique selling point of formal modeling is that it allows early analysis of system properties. Problems identified during the requirements analysis and design phase are easier to fix than problems identified during test and integration, which saves costs and improves the time-to-market and product quality. However, in the area of real-time systems this is notoriously difficult to achieve. The reason for that is two-fold. First of all, the general tendency is to focus on the functional requirements of the product first and foremost. The non-functional requirements (such as timeliness and throughput) are only considered in practice after the functional design is completed. Ask any software engineer how much time it takes to execute the code they wrote and in most cases they are not able to provide the answer. But more importantly, they often do not consider it to be their problem at all. The general belief is: “Surely, the hardware will be fast enough”. The wellknown Moore’s law [5] has not helped to change this attitude; many projects were saved by the fact that available hardware at the time of product release was indeed faster than the state of the art at the time of design, or hardware has become so cheap that is was economically viable to increase the computing or communication capacity. This trend seems to be no longer feasible, in particular in the embedded systems area, see for example the on-line article [6]. Companies are forced to produce at increasingly lower cost to remain competitive in poor market conditions. Secondly, the analysis techniques currently used in industry are not very effective. For example, worst-case execution time (WCET) analysis is indeed possible, but only if you have the source code, the compiler and know the target platform. These are available rather late in the design, in particular when the hardware is developed in parallel to the software, which is often the case in embedded systems. Modern CPU and System-on-Chip architectures have features (such as multi-stage instruction pipe-lining and advanced caching algorithms) where WCET analysis can only provide coarse results. Often benchmarking, running and measuring pieces of application code on the real target hardware, is the only practical solution to circumvent this problem. Alternately, one has to accept a large margin of error which will result in a conservative and over dimensioned design. Similarly, rate monotonic analysis (RMA, [7]) can be used to analyze schedulability, but only if all the tasks are periodic. Earliest deadline first (EDF, [8]) scheduling is known to be optimal for non-periodic tasks but no efficient implementation exists. The time-triggered architecture (TTA, [9]) does offer a solution to increase predictability by apriori distributing the capacity of the resources over all available tasks, but also at the cost of over dimensioning. With respect to the first problem, the root cause is the notations used to design software. Performance is often considered a “second-class” citizen because there is no easy way to specify this type of requirements. For example, Real-time Object-Oriented Modeling (ROOM, [10]) only supports the notion of timers for which the semantics (e.g. resolution, accuracy) is depending on the target platform used. Selic et al claim that this is sufficient for soft real-time systems but they also admit that it is probably not suited (and was never intended) for hard real-time systems. Results obtained from simulation might differ significantly from the code running on the target environment. However, the situation is improving with the advent of UML2 (which has borrowed a lot of concepts from ROOM) and the Profile for Schedulability, Performance and Time (available at http://www.uml.org). At least it is now possible to annotate software models with performance data using an industry-wide accepted notation. The mentality problem however, can only be solved by education and training. With respect to the second problem, a lot of progress has been made the last few years. Model checkers such as FDR2 (http://www.fsel.com) and μCRL (http://homepages.cwi.nl/∼mcrl/ ) can deal with very large state spaces, making analysis of concurrency practically usable. Similarly, timed-automata model checkers, in particular the tools UPPAAL and TIMES (http://www.uppaal.com and http://www.timestool.com respectively) are improving significantly as well, allowing analysis of realistic timing and schedulability problems. But all these techniques use an input language that is tailored for formal analysis rather than for design, which makes it hard to use by practitioners, even despite the nice graphical front-ends of the latter two tools. Moreover, the improved power of the tools itself has not reduced the inherent problem in this class of languages: even seemingly simple models can lead to large state spaces that are very hard to analyze. Expert advice, which is often lacking in an industrial environment, is often the only solution to find alternative modeling strategies that prevent (or circumvent) such situations. Solutions are also proposed from the discrete event systems domain, where simulation based techniques are often used instead of model checking. It is often impossible to claim completeness during analysis because the state space of the model is potentially infinite which makes exhaustive simulation impossible. Nevertheless useful results can be obtained using these techniques. For example the Parallel Object Oriented Specification Language (POOSL, [11]) with its support tools SHESim and Rotalumis come from this domain. The language has been formally defined using timed probabilistic labeled transition systems and the simulation algorithm was proven to be correct with respect to the language semantics. The simulation algorithm consists of a two phase execution approach, where either processes execute asynchronously to completion or time passes synchronously for all processes at once. The language is sufficiently expressive to model timing requirements but these requirements have to be encoded explicitly, for example using modeling patterns. Matlab, which is well-known in industry (http://www.mathworks.com) provides functionality to specify timing requirements using Simulink and Stateflow. However, the notation is limited to state transition diagrams only and its semantics are determined by the type of mathematical solver used. 3 The VDM++ language The book by Fitzgerald et al, [3], presents VDM++ using several case studies and deals with concurrency in chapter 12. Note that the real-time language extensions presented here are not discussed in the book. The official language reference manual is [12], which is also available at http://www.vdmbook.com/tools.php. The real-time language extensions are currently only described in [13,14] and are illustrated by the case study presented in [15]. We will repeat the essentials from these documents here for the sake of completeness and discussion. Unfortunately, it is not possible to show the case study we performed in the BODERC project for reasons of confidentiality. In stead, the famous “Dining Philosopher” problem of Edsgar Dijkstra [16] will be used as a carrier throughout this paper. The story goes as follows: a group of philosophers joins for dinner at a table and each of them brings one fork. But the philosophers are only allowed to eat if and only if they have two forks, one in each hand. So, they have to borrow a fork from their colleagues to be able to eat. The aim is to find an algorithm that allows all the philosophers to eat, but without fighting about the forks, which are critical resources. A fork can be picked up by only one philosopher at a time. In contrast to the original “Dining Philosopher” problem, where only the fork of the adjacent philosopher at the table can be borrowed, here we do not care which fork is taken. For simplicity, a philosopher may take any fork from the table, as long as it is free. Furthermore, we have added an explicit limit to the number of times a philosopher can eat. This feature was introduced for practical reasons as well. While the original algorithm continues indefinitely, the algorithm presented in this paper always terminates, which makes it easier to study with VDMTools. Last but not least, we will also use the example as a carrier to introduce the notion of time in the specification, which goes beyond the scope of the original example. 3.1 Dealing with concurrency VDM++ distinguishes active and passive objects. The latter only react when their operations are called, the former have their own thread of control and after start up they do not necessarily need interaction with other objects to continue. As shown in Figure 1, we will model the table as a passive object and the philosophers as active objects. The class Table has an instance variable forks to count the number of available forks on the table. The operations takeFork and releaseFork are used to either pick up a fork or put it down again on the table. The operation IamDone is used to count the number of philosophers that are done eating. The constructor